P0-1: invert conda/driver_load_probe.py from a fail-OPEN denylist to a
fail-CLOSED allowlist. A repackaged native ODBC driver that fails to load now
FAILS the DB-less pre-publish gate instead of passing on any unrecognized
exception. Only a clean connect or a connection-stage diagnostic the loaded
msodbcsql driver alone can emit (ODBC branding, network provider, TLS, auth)
counts as PASS. Defer 'import mssql_python' into main() so the classifier is
unit-testable without the compiled extension. Adds tests/test_026 (22 no-DB
tests).

P0-3: gate the conda release on package METADATA, not folder names/counts.
New conda/validate_conda_release.py reads each package's authoritative
info/index.json (zstd) and validates real subdir == folder, allowed subdirs,
the full (subdir x Python) binding matrix, exact/consistent versions, and #706
binding<->companion pairing. Catches a mislabeled subdir and the 8e7f217
dropped-win-64-variant regression the count gate missed. Rewires
OneBranchPipelines/steps/conda-release-step.yml to call it. Adds tests/test_027
(11 tests incl. a real .conda round-trip).

Decision 2(b): Alpine is a supported, PR-tested platform, so its wheels must be

fixed too (not dropped, not documented-as-limitation). Extends the libltdl

self-contained-payload work to musl:

- eng/scripts/patch-linux-odbc-libs.sh now auto-detects libc + arch and patches

  the matching distro subtrees: a glibc-built libltdl (manylinux, dnf) for

  debian_ubuntu/rhel/suse, a musl-built libltdl (Alpine, apk add libtool) for

  alpine. One build per (libc, arch) serves all that arch's distro subtrees. It

  also drops a per-dir LIBLTDL_LGPL_LICENSE.txt notice.

- mssql_python_odbc/libs/LICENSING: document libltdl (GNU Libtool, LGPL-2.1-or-

  later, dynamically linked) covering the existing macOS libltdl.7.dylib and the

  new Linux libltdl.so.7 (compliance; precedent = macOS already vendors it).

- build-odbc-all-stage.yml: musllinux_1_2_{x86_64,aarch64} wheels now also REQUIRE

  libltdl.so.7 (fail-closed), since the Alpine test leg's system libltdl masks

  the OSError today.

- eng/scripts/audit_bundled_binaries.py (new): allowlist-driven ELF/Mach-O/PE

  dependency audit (gate step 3). Every dep must be BUNDLED, BASE (OS/libc), or

  DECLARED (openssl/krb5 [linux], vc14_runtime [win]); anything else fails. ELF

  binaries that need a bundled sibling must carry an \ RUNPATH; macOS

  absolute non-system install names (e.g. /opt/homebrew) fail regardless of

  basename; --require-arch asserts Mach-O slices (the Intel-agent substitute for

  the arm64 runtime import). Validated locally: Windows PASS, Linux FAIL on the

  missing libltdl.so.7, macOS FAIL on libodbc.2.dylib's /opt/homebrew libltdl.

Cross-build the self-contained mssql-python conda package for win-arm64 on the native x64 Windows agent via CONDA_SUBDIR, mirroring the existing osx-arm64 cross leg. bld.bat now extracts the cp<CONDA_PY>-win_arm64 code wheel WITHOUT running Python when the arm64 host Python cannot execute on x64 (build.sh already does this for osx-arm64); meta.yaml skips pyc on win too. build-conda-packages.ps1 adds Anaconda defaults for the win-arm64 build host env and the verify solve (win-arm64 python 3.12/3.13 and cryptography live only on defaults, azure-identity/msal are noarch on microsoft), makes the arm64 verify best-effort with an import auto-skip, and auto-accepts the defaults ToS. The pipeline adds a continueOnError win-arm64 leg scoped to Python 3.12-3.14 (the intersection of available win_arm64 wheels and win-arm64 conda python).

Validated locally: real cross-build produced win-arm64/mssql-python-1.13.0-py314_0.conda (subdir=win-arm64, arm64 ddbc_bindings.pyd + arm64 driver, depends=azure-identity/python3.14/vc14_runtime); the full transitive dep closure resolves for 3.12, 3.13 and 3.14 (mssql-python -> azure-identity/msal -> cryptography 49.0 + cffi + vc14_runtime).

…onPreference=Stop

The verify loop's conda env remove (on an absent env -- fresh agent / first run) and conda run (when the cross-built arm64 Python cannot execute on the x64 host) write to stderr on their NON-FATAL paths. Under the script-wide ErrorActionPreference=Stop, PowerShell escalated that to a terminating NativeCommandError, aborting BOTH the win-64 (blocking) and win-arm64 (best-effort) legs at conda env remove before any package was staged -- even though every conda package built successfully. Switch the verify section to Continue and gate control flow on LASTEXITCODE / Assert-LastExit, the same intent as the bash port's || true. Reproduced the NativeCommandError under Stop and confirmed no-abort under Continue; the native win-64 create + import path completes.

…leg passes + stages

The win-arm64 verify leg's last native command is the runnable-check conda run python that INTENTIONALLY fails (arm64 Python cannot launch on the x64 host -> exit 216 = ERROR_EXE_MACHINE_TYPE_MISMATCH); the script then skips the import and completes normally (CONDA_BUILD_OK, all three packages built and their deps resolved from pkgs/main win-arm64 + microsoft). But the validate-step .yml calls this script with the call operator in-session, so the lingering LASTEXITCODE=216 propagated to the caller's exit-code gate and failed the leg BEFORE staging. Add a trailing cmd /c exit 0 to reset LASTEXITCODE without PowerShell exit (which, under the in-session call, would terminate the whole step before it stages the packages). Verified end-to-end: & script leaves the caller at LASTEXITCODE=0 with the reset (216 without) and control returns so staging runs. Real failures still exit 1 via Assert-LastExit.

…sh plan)

Conda analogue of dummy-release-pipeline.yml (the PyPI dummy). Always NonOfficial, manual trigger, [TEST]-labelled. Downloads the consolidated conda packages from the conda-build pipeline, runs the SAME readiness gate the real conda-release-pipeline uses (conda-release-step with labelPrefix=[TEST]), then performs a DUMMY publish: a DRY-RUN that enumerates every package and prints the exact anaconda upload plan (per package/subdir/channel/label) WITHOUT uploading. Unlike PyPI -- where the dummy releases via ESRP with the harmless Maven ContentType -- anaconda-client has no safe alternate target, so the dummy never runs anaconda upload; a real staged test to a non-production org goes through conda-release-pipeline.yml with a test condaChannel + publishToConda=true. YAML validated locally.

…prints upload plan)

…icial publish

…ch assert, exact matrix/RUNPATH, publish version pin); drop dead CONDA_ALLOW_UNSIGNED_PATCH

…S gate required/fail-closed mode

…cksums, fail-closed on override)

…shes flagged by DevSkim

…e; clearer unavailable error

…build variant)

…d DYLD_FALLBACK hook

The bundled ODBC driver dlopen's OpenSSL (bare libssl/libcrypto) for TLS (Encrypt=yes)
on macOS just like Linux, but macOS dyld ignores rpath for a bare-leaf dlopen, so the
Linux $ORIGIN RUNPATH climb has no on-binary twin -- and the signed driver can't be
patched. So:

- meta.yaml: declare `openssl >=3,<4` on macOS too (lands libssl.3.dylib in $PREFIX/lib).
- build.sh: emit activate.d/deactivate.d hooks that prepend $CONDA_PREFIX/lib to
  DYLD_FALLBACK_LIBRARY_PATH on macOS, so a Homebrew-free Mac resolves the env's own
  openssl instead of failing "OpenSSL library could not be loaded". Fallback (not
  DYLD_LIBRARY_PATH) so a Homebrew box is unchanged; deactivate restores the prior value
  exactly (incl. was-unset). macOS packages only.

Hook save/restore validated (bash -n + source/restore, unset and preset cases). The
end-to-end macOS TLS self-containment needs the Homebrew-hidden Encrypt=yes repro to
confirm the driver honors DYLD_FALLBACK for its bare-soname dlopen.

…ved the driver dlopens OpenSSL by absolute path only, so DYLD_FALLBACK (bare-leaf only) cannot redirect it. Preload approach under test.

…py unreachable by the bundled driver

…rm64 package cant vendor an x64 driver (Sumit review)

…n executability

bld.bat keyed ODBC_ARCH off whether %PYTHON% could run: the cross (arm64-on-x64)
leg set win_arm64, the native else leg hardcoded win_amd64. On a NATIVE Windows
arm64 conda-build host the arm64 Python IS executable, so it fell into the else
leg and selected the win_amd64 ODBC wheel -- the package would fail to find
mssql_python_odbc-...-py3-none-win_amd64.whl or vendor the x64 driver DLLs,
leaving no libs\windows\arm64 payload for the loader.

Derive the arch once from the conda target platform (target_platform, with
CONDA_SUBDIR fallback): win-arm64 -> win_arm64, else win_amd64. Use it for the
code-wheel glob and the ODBC wheel, and guard the x64 mssql_py_core strip on
win_arm64. Python executability now only chooses pip-install (native) vs
tar-extract (cross). (Sumit review, PR #734.)

… mssql_py_core in win-arm64 wheels)

…e bulk copy)

Restore path for PR #737: the win-arm64 wheel now vendors the matching arm64
mssql_py_core, so stop unconditionally stripping it. bld.bat keeps the core when
the extracted wheel has a matching-arch native ext (mssql_py_core.cp<ver>-<arch>.pyd)
-- shipping bulk copy on win-arm64 -- and strips only when a legacy x64 core is
present (a pre-#737 wheel), so the package never carries a core that can't load on
the target. Self-healing: bulk copy turns on automatically once the arm64-core wheel
is the conda-build input, with no build failure during the rollout gap.